LGTM

just as a side not, support for multiple paths in watch definition could also be implemented as some syntaxic sugar in compose-go, i.e. while parsing we translate multiple path values into a set of watch rules, with same action definition, for each declared paths. Somehow comparable to the way we translate port ranges into a set of simpler port declarations.

This would avoid changes to compose and keep logic simpler (especially to later introduce support for match patterns). wdyt?

LGTM

just as a side not, support for multiple paths in watch definition could also be implemented as some syntaxic sugar in compose-go, i.e. while parsing we translate multiple path values into a set of watch rules, with same action definition, for each declared paths. Somehow comparable to the way we translate port ranges into a set of simpler port declarations.

This would avoid changes to compose and keep logic simpler (especially to later introduce support for match patterns). wdyt?

Hey @ndeloof :) Could you confirm that when you say sugar syntax do you mean to represent the path like this? (keeping the string type in compose-spec, etc?)

...
   develop:
      watch:
        - path: api;other;*.txt;web/some/really/super/long/path; ### assuming ; as a delimiter (por example) for each path
          action: rebuild

Nope, I mean path can be a string or list in yaml as you suggested, but compose-go while loading would actually convert this into a single path string per watch rule, so that you don't need this PR.

i.e.

   develop:
      watch:
        - path: [api, other]
           action: rebuild

would be cannonical-ized into:

   develop:
      watch:
        - path: api
           action: rebuild
        - path: other
           action: rebuild

Actually I see more benefits in pattern support vs multiple paths, which sounds a corder case to me

Nope, I mean path can be a string or list in yaml as you suggested, but compose-go while loading would actually convert this into a single path string per watch rule, so that you don't need this PR.

i.e.

   develop:
      watch:
        - path: [api, other]
           action: rebuild

would be cannonical-ized into:

   develop:
      watch:
        - path: api
           action: rebuild
        - path: other
           action: rebuild

Actually I see more benefits in pattern support vs multiple paths, which sounds a corder case to me

I see, I will make this changes. The pattern matching can translate into multiple files though so these features are actually related. And can be annoying to define multiple watch rules for the same action (rebuild and restart)

The pattern matching can translate into multiple files though so these features are actually related

I don't get this. A basic path matches multiple files (anything under folder matches). A pattern is just more restrictive. This is unrelated to multiple values in path (which we can support, but this is another feature then)

My initial thoughts to implement this feature was to introduce an includes attribute to define pattern filtering for files under path, but it makes sense for a simpler approach to make path a pattern. The fixed part of the pattern would then declare the source path, and the match expression the filter
For illustration:

path: src/*.txt # watch src/ but only consider .txt files
target: /app

File src/foo.txt would be copied into container as app/foo.txt
This would be equivalent to a negative ignore:

path: src/
ignore: !*.txt # AFAIK this isn't supported
target: /app

.. but with a more comprehensible syntax :P

so imagine the case where the target is a file

  path: app/*.txt
  target: app/some.txt
  action: sync

in this case, we need to be careful and through some error. During validation, when target is a file, compose-go needs to assert the relation 1 to 1 is true or else it will have a weird behaviour in this case. That is why I was assuming path could be treated as a []string to be easier to validate this case.

The presented example I would assume it should throw an error or show a warning at least as multiple files can overwrite one file in the container

target can't be a file, MUST be a folder. If you want to sync with file app/some.txt inside container, source MUST be some.txt. What you describe is way more complex use-case but just support for pattern

Remember sync is basically equivalent to a bind mount (without the constraints of a bind mount)

Closing this PR as we merged #12584
I'd be happy to experiment letting path use wirldcards, as some syntaxic sugar to define include pattern. Would you like to investigate this feature ?